Template talk:Wad

Author cat bug
I've used "|authors=Various" instead of "|author=some name" many times already, and that doesn't result in the bug occurring now on ZDCMP1, which displays at the top of the page. Anyone know how to get rid of it?
 * will be worth if  isn't set -- and that's not an empty string, so  will be true. On the other hand,  will be worth  is  isn't set. Therefore,  will be worth an empty string is  isn't set, and the  will be false, as intended. --Gez (talk) 09:48, 30 March 2017 (CDT)


 * Indeed, but now a single existing author does not get his levels category added, as intended: e.g. Earth (WAD) and Going Down. Further puzzling ensues? --Xymph (talk) 06:44, 31 March 2017 (CDT)


 * The levels category should be on individual map pages rather than WAD overviews. At this very minute I'm making a very basic skeleton for Polygon Base, where using type L does add the author's category. --Eris Falling (talk) 06:50, 31 March 2017 (CDT)


 * Ah of course, thanks for clearing that up. --Xymph (talk) 07:34, 31 March 2017 (CDT)

Type/category for small mapsets?
Type 'l' adds category Level WADs, type 'e' Episode WADs, but some WADs have just two-five maps. E.g. Boothill, Deus Vult, For Whom the Bell Tolls, Galaxia, etc. Too few for an episode, so I've been using type 'l' in some cases, but then the overview page gets added to the author's levels category in addition to the individual maps, e.g. Pavel Hodek for Galaxia. And sometimes I used 'e' which isn't quite a correct fit either. But leaving out the type parameter results in the overview page getting added to category PWADs without maps, which would be far more inappropriate. My choices so far have been somewhat arbitrary anyhow.

Can we define a category for small mapsets, and what should it be named? "Mapset WADs", "Mini WADs"... any better ideas? --Xymph (talk) 13:09, 8 April 2017 (CDT)
 * I think "episode" is fine for 2-14 levels. --Gez (talk) 13:40, 8 April 2017 (CDT)
 * Agreed, I think I've seen quite a few of these WADs referred to as things like "7 map episode" by their authors. --Eris Falling (talk) 13:56, 8 April 2017 (CDT)


 * Seven, sure. But for two or three, "episode" sounds like a misnomer to me. The consensus on what constitutes a Doom II episode seems pretty strong. But if we agree (and I am not yet convinced) to expand the range into low numbers for the purposes of categorization, then at least its description would need to be adjusted from "are approximately" into something like "are up to approximately". --Xymph (talk) 14:17, 8 April 2017 (CDT)


 * My suggestion would be to create a Category:Multilevel WADs that occupies the space between 2 and 8-ish levels. --Quasar (talk) 13:41, 11 April 2017 (CDT)
 * Chex Quest's episodes are five-levels, why would they not be episodes? --Gez (talk) 13:58, 11 April 2017 (CDT)
 * I think the real problem is one of authorial intent and that trying to nail it down to numbers is perhaps futile, in light of that example. For example, a single-level wad that also includes a bonus tweaked version of the map with tons of monsters, or a myhouse.wad style level as a joke, for example, hardly constitutes an episode. But Chex Quest on the other hand was explicitly designed to function as such despite its "non-standard" level count. Part of the equation is clearly thematic consistency and/or story line. --Quasar (talk) 19:50, 11 April 2017 (CDT)


 * "Multilevel" sounds fine and I agree the authorial intent can be taken into account rather than settling on a fixed numeric threshold. E.g. Dark 7 sounds it was intended as a 7-map episode, while The Final Gathering and SkePLand seem to group several distinct levels, The Artifact and For Whom the Bell Tolls were merely split up because they were too big for a single level, and Galaxia's maps aren't even adjacent. So perhaps the Multilevel WADs category won't be very large, but it still serves its purpose where "episode" is a misnomer. I'm willing to do the reassignments and then individual cases can always be debated further. --Xymph (talk) 06:12, 12 April 2017 (CDT)


 * IMO this is completely fair. I only wanted to make sure non-algorithmic situations could be accounted for, e.g. Galaxia's readme saying "level", or a shovelware DM compilation (some of which are notable!) which is never called an "episode" due to the complete lack of planning/coherence and all the maps having prior standalone releases.    Ryan W (usually gone) 17:54, 13 April 2017 (CDT)


 * Ideally we should follow the practices of the wider Doom community (extending Eris's point above). That said, we lack an  which aggregates 23 years of sites and postings on demand  :>  so we must fall back on an algorithm again.  I personally am OK with any of the options above, but suggest two small things:  (1) The bot shouldn't categorize the same mod twice, in case a human editor adjusted the categorization later (based on reviews or readmes or whatever).  (2) Describe the decision tree on the category talk page, in case our successors want to re-evaluate.  US$0.02.    Ryan W (usually gone) 18:25, 11 April 2017 (CDT)


 * (1) Again, no bot is involved in this topic, so a hard-coded algorithm is not needed. (2) Okay. --Xymph (talk) 06:12, 12 April 2017 (CDT)

Port2
Projects like Doomworld Mega Project 2012 and its sequels feature maps built for several different ports, you've got vanilla, limit-removing, Boom, ZDoom, GZDoom and so it goes on...So far this is the only situation I've run into where the port2 parameter would be useful, but it only takes one value. Could it be expanded to take multiple values or should there be new parameters like port3 and port4 added for cases like this? --Eris Falling (talk) 07:03, 10 April 2017 (CDT)
 * The aim of port2 was to handle things like Doom: The Lost Episode which targets both ZDoom and Eternity. I suppose adding further portn parameters would be the simplest, if not the most elegant, way to extend this, and it'd make sense. --Gez (talk) 08:09, 10 April 2017 (CDT)

Repair and tweak
IMO two things should happen. Ryan W (living fossil) 20:39, 15 March 2018 (CDT)
 * Convert "Doom 2" and "Doom2" &rarr; "Doom II" in the rendered text as well as the category name. This is not only for consistency, but the current code manages to misinterpret "Doom2" as "Doom" in the IWAD row.
 * Change the cacoward parameter from an ordinal to a year, matching the Top 100 parameter. People have already done this at times (e.g. the nomination threads), but it's now the endorsed method, and for the same reasons stated there, it ought to increase clarity.

Looking more closely at the markup, the first issue is actually that "Doom 2" rendered as "Doom 2". Changing "Doom2" to "Doom" is part of collapsing the entire classic series into "Vanilla Doom", which is appropriate, therefore probably intentional. Ryan W (living fossil) 21:59, 15 March 2018 (CDT)

The cacoward part obviously requires a mass edit to update the existing transclusions. I doubt it will take long, but even so, I gave the parameter a default value so the cacoward boxes will hide themselves until I arrive, instead of giving an error or warning. Ryan W (living fossil) 22:34, 15 March 2018 (CDT)

More than two ports
Velocity CTF needs three ports listed. Now we could add a port3 parameter, but we have to establish at what boundary it becomes "too much" to keep adding separate port parameters. If we feel that's been met already, then my suggestion would be to have an alternate "ports" parameter that, if provided, disables output of all the others and allows manual listing of the ports, but in turn, requires manual categorization of the article as well, since we can't parse an arbitrary input string w/o installing Lua scripting (blech). --Quasar (talk) 19:50, 2 February 2019 (CST)
 * The three ports being Odamex, Skulltag/Zandronum and ZDaemon, right? Perhaps a catch-all category (similar to "Boom-compatible" could be made for them. Not sure how to call it, though. "Multiplayer" is too generic because it's perfectly possible to have MP with other ports, "csDoom-compatible" is a bit vague. I'd be in favor of just adding a port3 parameter for the time being as it seems the least amount of work, and do the "ports" workaround later if it is ever needed. --Gez (talk) 13:42, 3 February 2019 (CST)

'caco' and 'top' parameters both appearing in one article
From Talk:RTC-3057, I made a change so the column layout doesn't break when both parameters top and caco are filled. Two columns for the Top 100 and two columns for the Cacoward are appearing on the same  row, breaking the table layout that uses either one column (colspan = 2) or two columns on each row.

RTC-3057's demo was in the Top 100 WADs of All Time for 2003, then its Hub 1 release a year later was named to the first Cacowards in 2004. It's the only WAD that requires this template to use both parameters. Forcing the Cacoward columns onto a new row is needed. if top is not empty for Top 100 if caco is not empty for Cacoward if top is empty and caco is empty to close the Link row --Afterglow (talk) 14:37, 12 October 2020 (CDT)

Needs a new type for gameplay mods
Per the discussion today at Talk:Partial conversion it's clear that gameplay mods are separate entities from partial conversions. Thus a new Wad template type is needed for articles like Painslayer and Corruption Cards. We also need a new Category:Gameplay mods that would be auto-populated by this new type.

On a related note, neither of these mods (or just about any GZDoom mod for that matter) are technically PWADs. They're .pk3 archives with Decorate, Zscript, multimedia resources, etc. Not exactly the same as the traditional .wad format. So perhaps they shouldn't be given WAD categories? It may not really matter, though, since they're more-or-less functionally equivalent to a WAD for the player. --PhilthyPhilistine (talk) 16:19, 21 December 2021 (CST)


 * Using the same template would be convenient, but the iwad[2] and port[2] parameters may not apply (in the same way) to gameplay mods as they do to mapsets/PCs/TCs. Any thoughts on this, and how to handle the distinction if that needs to be made? --Xymph (talk) 08:35, 22 December 2021 (CST)


 * The iwad[2] is still needed for SWWM GZ, and port[2] as well for cases like Brutal Doom that still support GZDoom + Zandronum. Would it be easier to create an entirely new template with just a subset of this one? That way it could have a param for pwad=true/false. So mods that are pwads could have the category, but pk3s wouldn't. (I just crossed this out because of noticing Category:GZDoom WADs for the first time. What I wrote is too minor a distinction to make special effort for.) --PhilthyPhilistine (talk) 08:42, 22 December 2021 (CST)


 * PK3 is just a different container format, it can contain maps (WAD lumps) just as well. PK3 mods with maps are categorized in Episode WADs, Megawads, etc. all the same. A separate (complex) template increases maintenance efforts, and the risk that someone picks the wrong template for their mod article. The template now has the 'g' parameter, give it a try how that works for you. --Xymph (talk) 09:39, 22 December 2021 (CST)

Looking more closely at the current auto-populated categories for the mod articles I linked, I suggest that the new Category:Gameplay mods be a sub-cat of the current Category:PWADs without maps -- in the same way Music Packs and Texture Packs are. And for each mod article, it makes sense to retain the Category:PWADs by name they currently have. (In other words, this new template type shouldn't need much special logic.) --PhilthyPhilistine (talk) 09:26, 22 December 2021 (CST)

The new type seems to be working properly. I only changed Brutal Doom so far. Will be offline for a while but can change others later on. Thanks for adding it. --PhilthyPhilistine (talk) 09:47, 22 December 2021 (CST)

Type field instructions
The instructions for the type field currently state "the default is a gameplay mod". Since that type was just added earlier today (per the prior topic above) that statement is inaccurate. I know this because Brutal Doom's template didn't have a type field at all until I added it today. So that statement should be removed or re-worded. --PhilthyPhilistine (talk) 14:57, 22 December 2021 (CST)


 * Hmm, good point, the default category is which is now the parent of ; I overlooked that. So now gameplay mods can be subcatted, leaving few (which kind?) mods in the main category? Perhaps the new type & cat took things one step too far? --Xymph (talk) 15:10, 22 December 2021 (CST)


 * No, I think the new cat and the new template type are the correct approach. It's always better to be explicit about these things. It may be best to leave the template code as-is and just remove that statement in the instructions. I (and others if you want to help :) haven't yet changed the template types of the gameplay mod articles (which are either 'p' type or no type at this moment). After making these changes, should be empty or largely empty except the sub-cats. Is that really a problem though? It's better to have the sub-cats the way they are now. --PhilthyPhilistine (talk) 15:22, 22 December 2021 (CST)

'p' and 't' types not needed
The 'p' type for partial conversion is no longer needed. (Or, at this moment, won't be needed soon after the changes discussed in the prior 2 sections here.) The reason is that PCs are now defined as map(s) + other stuff (gameplay changes and such). Thus any PC is also a map and categorized with one of the map types. Likewise, 't' for total conversion is also redundant. Taking a quick look at several TC articles, they use the proper map type already. --PhilthyPhilistine (talk) 17:54, 22 December 2021 (CST)


 * Mods can have type p/t and cat episode/megawads in the footer, or vice versa with type u/e/m and cat PC/TC. The size category ensures the mod appears in the group with mapsets of similar size. How that is defined isn't terribly important, but this wad template needs to continue to support all types. --Xymph (talk) 03:40, 23 December 2021 (CST)


 * So are you saying the template can support multiple type values? Otherwise a TC is going to use the appropriate map type. And, based on last night's discussion with Quasar, who knows what a PC actually is/was. (So in that vein, it makes sense to keep 'p' around until that ever gets sorted out.) --PhilthyPhilistine (talk) 13:05, 23 December 2021 (CST)


 * No, but using one type in the template doesn't preclude adding another category in the footer of an article... --Xymph (talk) 13:17, 23 December 2021 (CST)


 * Gotcha, one can use the 't' type and manually add the map type category. Okay, no need to change things for editor flexibility. --PhilthyPhilistine (talk) 13:19, 23 December 2021 (CST)


 * I've been doing it the other way around, since all mapsets have some size type, but not all are a PC/TC. So it made sense to me to make that the 'extra' category, which then gets sorted later/last in the page footer. --Xymph (talk) 13:22, 23 December 2021 (CST)

Official Add-ons
In light of the ever-increasing number of official add-ons, I think it would be a good idea to have an extension of the template, similar to what we have for the Top 100 WADs of All Time or the Cacowards, where a separate small box is added at the end of the infobox for whatever WAD was added as part of the official add-ons. This would be a very simple change to make to the template, but the only problem is, I cannot right now think of what icon we could use for this... Any ideas? --Dynamo128 (talk) 06:00, 19 October 2022 (CDT)


 * Fine with me. Does the add-ons menu in the port use an icon that might be suitable identification? Also, the text for the additional box needs to be drafted. --Xymph (talk) 03:57, 20 October 2022 (CDT)
 * If you can't find anything more suitable, then I suppose the Bethesda publishing logo (concentric black and white squares) would work. E.g. here. --Gez (talk) 04:58, 20 October 2022 (CDT)
 * The top-left corner of this menu image has an icon (looking like a bird?). Is that a general Xbox-related icon or specific add-ons one? --Xymph (talk) 05:46, 20 October 2022 (CDT)
 * I believe that to be the user avatar for Xbox or something similar, yeah. I checked the PC version and there does not seem to be any icon, nor is there a specific icon for the program itself (it's just the cacodemon for the .EXE, similar to Doom95 I believe). --Dynamo128 (talk) 06:11, 20 October 2022 (CDT)
 * I'd prefer we avoid use of trademarks in that kind of way. Simple decoration and indication of something not strictly related to the topic aren't really fair dealing when it comes to those. --Quasar (talk) 12:24, 20 October 2022 (CDT)
 * In that case, what would be a good icon to use? --Dynamo128 (talk) 14:08, 20 October 2022 (CDT)

Cannot have "no" port value
Regardless of what you put into the port parameter the article will be categorized into a bogus category. This needs to be fixed. --Quasar (talk) 01:54, 22 October 2022 (CDT)

IWADs
For mods such as Project Osiris, which are not dependent upon any iwad, it would be a good idea to have a category in the iwad= parameter be something like "Standalone", which could redirect to this. --Dynamo128 (talk) 05:29, 20 December 2022 (CST)
 * If something is a standalone game, the WAD template is not intended for it. On existing articles, only two use the InfoboxSourcePort template instead, although that may also not be suitable in other cases. --Xymph (talk) 05:54, 20 December 2022 (CST)
 * Right... and I think it's time to change that, because the template works just as well for an IWAD. It is, after all, the *wad* template, not the PWAD template. Naturally, that's just my POV, which is why I brought it up here. --Dynamo128 (talk) 06:00, 20 December 2022 (CST)


 * There's a significant amount of info this template requires that won't make sense in that situation. For example, "IWAD". Is it supposed to say "Self" there? Won't make sense. --Quasar (talk) 10:47, 20 December 2022 (CST)
 * I personally think "Standalone" (or even just obfuscating that particular bit, as certain other fields are, such as the caco field) works just fine. It could also be tied to the category automatically that way, as noted. --Dynamo128 (talk) 10:50, 20 December 2022 (CST)